REPORT  DOCUMENTATION  PAGE 


Form  Approved 

OMB  No.  0704-0188 


The  public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  Information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  Information,  Including 
suggestions  for  reducing  this  burden,  to  Department  of  Defense,  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports  (0704-0188),  1215  Jefferson  Davis  Highway, 
Suite  1204,  Arlington,  VA  22202-4302.  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  any  penalty  for  falling  to  comply  with  a  collection  of 
information  if  it  does  not  display  a  currently  valid  OMB  control  number. 

PLEASE  DO  NOT  RETURN  YOUR  FORM  TO  THE  ABOVE  ADDRESS. 


2.  REPORT  TYPE 


1.  REPORT  DATE  (DD-MM-YYYY) 

OCTOBER  2013 


4.  TITLE  AND  SUBTITLE 


Conference  Paper 


A  Model  for  Trust-based  Access  Control  and  Delegation  in 
Mobile  Clouds  (POST  PRINT) 


3.  DATES  COVERED  (From  -  To) 

APR  2011  -  JUN  2013 


5a.  CONTRACT  NUMBER 

IN-HOUSE  GGIHZORR 


5b.  GRANT  NUMBER 


5c.  PROGRAM  ELEMENT  NUMBER 


6.  AUTHOR(S) 

Colorado  State  University:  Indrajit  Ray,  Dieudonne  Mulamba, 
Indrakshi  Ray 

Air  Force  Research  Laboratory.  Keesook  J.  Han 


5cl.  PROJECT  NUMBER 


GGIH 


5e.  TASK  NUMBER 


5f.  WORK  UNIT  NUMBER 


7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES)  8.  PERFORMING  ORGANIZATION 

Colorado  State  University,  0100  Campus  Deiivery  Bidg,  Fort  Coiiins,  CO  80523  report  number 


10.  SPONSOR/MONITOR’S  ACRONYM(S) 

AFRL/RI 


11.  SPONSORING/MONITORING 
AGENCY  REPORT  NUMBER 

AFRL-RI-RS-TP-201 3-058 


Air  Force  Research  Laboratory/RIGA  525  Brooks  Rd,  Rome  NY  13440 


9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

Air  Force  Research  Laboratory/Information  Directorate 
Rome  Research  Site/RIGA 
525  Brooks  Road 
Rome  NY  13441-4505 


12.  DISTRIBUTION  AVAILABILITY  STATEMENT 

Distribution  Approved  For  Pubiic  Reiease;  Distribution  Uniimited. 
PA  Case  number:  88ABW-2012-2127,  dated  2  May  2013 


13.  SUPPLEMENTARY  NOTES 

This  paper  was  pubiished  in  the  Proceedings  of  the  27*'^  Annuai  IFIP  WG  11.3  Working  Conference  on  Data  and 
Appiications  Security  and  Privacy  (2013  DBSec)  Newark,  NJ,  15-17  Jui  2013..  This  work  is  copyrighted.  Cne  or  more  of 
the  authors  is  a  U.S.  Government  empioyee  working  within  the  scope  of  their  Government  job;  therefore,  the  U.S. 
Government  is  joint  owner  of  the  work  and  has  the  right  to  copy,  distribute,  and  use  the  work.  Aii  other  rights  are 
reserved  by  the  copyright  owner. 


14.  ABSTRACT 

Muiti-tenancy,  eiasticity  and  dynamicity  pose  severai  novei  chaiienges  for  access  controi  in  mobiie  smartphone  ciouds 
such  as  the  Android  cioud.  Accessing  subjects  may  dynamicaiiy  change,  resources  requiring  protection  may  be  created 
or  modified,  and  a  subject’s  access  requirements  to  resources  may  change  during  the  course  of  the  appiication 
execution.  Cioud  tenants  may  need  to  acquire  permissions  from  different  administrative  domains  based  on  the  services 
they  require.  Moreover,  aii  the  entities  participating  in  a  cioud  may  not  be  trusted  to  the  same  degree.  Traditionai  access 
controi  modeis  are  not  adequate  for  mobiie  ciouds.  In  this  work,  we  propose  a  new  access  controi  framework  for  mobiie 
smartphone  ciouds.  We  formaiize  a  trust-based  access  controi  modei  with  deiegation  for  providing  fine-grained  access 
controi.  Cur  modei  incorporates  the  notion  of  trust  in  the  Roie-Based  Access  Controi  (RBAC)  modei  and  aiso  formaiizes 
the  concept  of  trustworthy  deiegation. 


15.  SUBJECT  TERMS 


Access  Controi  Modei,  Deiegation,  Mobiie  Cioud  Security,  Trust  System 


16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION  OF 
ABSTRACT 

18.  NUMBER 

OF  PAGES 

19a.  NAME  OF  RESPONSIBLE  PERSON 

KEESOOK  J.  HAN 

a.  REPORT 

U 

b.  ABSTRACT 

U 

c.  THIS  PAGE 

U 

UU 

17 

19b.  TELEPHONE  NUMBER  {Include  area  code) 

N/A 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std.  Z39.1 8 


A  Model  for  Trust-based  Access  Control  and  Delegation 

in  Mobile  Clouds* 


Indrajit  Ray*,  Dieudonne  Mulamba*,  Indrakshi  Ray*,  and  Keesook  J.  Han^ 


*  Dept,  of  Computer  Science,  Colorado  State  University,  Fort  Collins,  CO  80523 
{indrajit,  mulamba,  iray}@cs . colostate . edu 
^  Air  Force  Research  Laboratory/RIGA,  525  Brooks  Road,  Rome,  NY  13441 
Keesook . HanOrl . af . mil 


Abstract.  Multi-tenancy,  elasticity  and  dynamicity  pose  several  novel  challenges 

TM 

for  access  control  in  mobile  smartphone  clouds  such  as  the  Android  cloud.  Ac¬ 
cessing  subjects  may  dynamically  change,  resources  requiring  protection  may  be 
created  or  modified,  and  a  subject’s  access  requirements  to  resources  may  change 
during  the  course  of  the  application  execution.  Cloud  tenants  may  need  to  ac¬ 
quire  permissions  from  different  administrative  domains  based  on  the  services 
they  require.  Moreover,  all  the  entities  participating  in  a  cloud  may  not  be  trusted 
to  the  same  degree.  Traditional  access  control  models  are  not  adequate  for  mo¬ 
bile  clouds.  In  this  work,  we  propose  a  new  access  control  framework  for  mobile 
smartphone  clouds.  We  formalize  a  trust-based  access  control  model  with  delega¬ 
tion  for  providing  fine-grained  access  control.  Our  model  incorporates  the  notion 
of  trust  in  the  Role-Based  Access  Control  (RBAC)  model  and  also  formalizes  the 
concept  of  trustworthy  delegation. 


Keywords:  access  control  model,  delegation,  mobile  cloud  security,  trust 

1  Introduction 

Smartphones  and  other  mobile  devices  are  increasingly  shifting  the  personal  computing 
model  away  from  traditional  desktops  and  laptops  to  mobile  cloud  computing.  In  this 
model,  cloud  computing,  mobile  devices  and  networks  seamlessly  interact  with  each 
other  to  provide  newer  types  of  services  that  were  previously  not  possible  (such  as  lo¬ 
cation  based  services).  The  unique  characteristics  of  mobile  cloud  computing  -  namely, 
multi-tenancy,  elasticity,  massive  scalability  [1],  and  mobility  -  introduce  novel  chal¬ 
lenges  to  authorization  and  access  control.  To  begin  with,  multi-tenancy  results  in  the 
co-residency  of  machines  (virtual  machines,  database  engines  etc.)  and  other  resources 
owned  by  different  clients  or  tenants  at  the  same  privileged  position  in  the  cloud  with 
respect  to  one  another.  As  a  result,  a  guest  operating  system  can  exploit  vulnerabilities 
in  the  hypervisor  and  run  processes  on  other  guests  or  the  host,  and  security  breaches 
can  arise  in  one  smartphone  client  and  propagate  to  another  easily  via  the  cloud.  Proper 
authorization  and  access  control  techniques  should  therefore  not  only  protect  tenant  re¬ 
sources  from  un-authorized  disclosure  and  modification  from  attackers,  but  also  should 
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allow  segregation  of  tenants  from  one  another,  and  isolation  of  computation,  storage 
and  network  resources  of  the  mobile  cloud  provider  from  tenants. 

A  mobile  cloud  environment  is  inherently  very  dynamic.  The  accessing  entities  may 
change,  resources  requiring  protection  may  be  created  or  modified,  and  an  entity’s  ac¬ 
cess  to  resources  may  change  during  the  course  of  an  application  execution.  Users  need 
to  dynamically  acquire  permissions  from  different  domains  based  on  the  services  they 
need.  Interactions  among  entities  may  occur  in  ad  hoc  manners  and  where  the  access- 
requesting  entity  may  not  be  known  in  advance  by  the  access-granting  entity.  In  such  sit¬ 
uations,  traditional  identity-based  access  control  models  such  as  Discretionary  Access 
Control  (DAC),  Mandatory  Access  Control  (MAC)  [2],  or  Role-based  Access  Control 
(RBAC)  [3, 4],  that  rely  on  the  access-granter  knowing  the  identity  of  access  requester 
beforehand  and  authenticating  the  requester,  can  no  longer  be  applied. 


Fig.  1.  Mobile  smartphone  cloud  application  illustrating  need  for  delegation 


Last  but  not  least,  in  a  mobile  cloud  environment  resources  are  often  distributed  and 
managed  by  different  service  providers  and  clients  move  from  one  service  provider  to 
another  to  obtain  the  needed  service.  To  support  a  specific  service,  there  is  frequently 
the  need  for  coordination  and  interaction  between  these  different  providers.  A  tenant  of 
one  service  provider  may  need  to  access  other  providers  to  obtain  the  relevant  service. 
This  is  illustrated  by  the  application  scenario  in  Fig.  1 .  A  mobile  smartphone  user  in¬ 
vokes  the  voice  assistant  application  (VAC)  on  her  smartphone  and  instructs  it  to  make  a 
reservation  for  that  evening’s  show  at  an  en-route  theater  closest  to  her  destination.  VAC 
computes  the  time  to  reach  the  destination  by  accessing  a  navigation  service  (NavC), 
identifies  candidate  theaters  by  consulting  a  location  service  (LocC)  and  selects  one 
from  the  list,  contacts  a  ticket  service  provider  cloud  (TktC)  for  a  reservation  and  con¬ 
tacts  the  user’s  mobile  wallet  provider  (MobWC)  to  purchase  the  ticket  from  TktC. 

For  accessing  different  services  the  authorization  sequence  can  potentially  be  as 
follows.  The  user  initially  authorizes  the  VAC  for  the  ticket  purchase  task;  however  the 
VAC  cannot  carry  out  the  task  on  its  own  and  therefore  needs  to  pass  on  the  authoriza- 
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tion  (or  portions  thereof)  to  various  other  cloud  providers.  Moreover,  if  the  different 
service  providers  are  all  tenants  of  one  or  more  infrastructure  cloud(s)  (as  shown  in 
Fig.  1),  then  each  service  provider  needs  to  rely  on  the  infrastructure  to  manage  ac¬ 
cess  control  to  its  resources.  Delegation  of  authorization  is  the  principle  that  allows  one 
service  provider  to  act  on  behalf  of  the  user  to  make  the  user’s  access  rights  available 
to  other  service  providers.  There  is  a  need  to  manage  and  mediate  interactions  with 
distributed  resources  having  distributed  administrators.  However,  authentication  of  the 
requesting  client  (required  in  conventional  access  control)  may  be  difficult  in  mobile 
smartphone  cloud  systems.  For  example,  it  may  not  be  possible  for  the  VAC  to  be  reg¬ 
istered  with  both  the  MobWC  and  the  TktC.  Hence,  delegation  may  need  to  proceed 
without  associated  authentication.  This  is  further  complicated  by  the  fact  that  often  the 
privilege  to  delegate  may  itself  need  to  be  delegated. 

In  this  work,  we  propose  a  new  trust-based  access  control  model  that  supports  com¬ 
plex  delegation  across  different  members  of  the  mobile  cloud  for  providing  fine-grained 
access  controls.  This  model  is  based  on  extensions  to  the  RBAC  model,  and  adapts 
concepts  from  the  trust-based  access  control  models  proposed  earlier  by  us  [5,6].  We 
assume  an  existing  context  sensitive  non-binary  trust  model  such  as  the  one  in  [7].  For 
this  work,  we  identify  the  different  trust-based  access  control  model  elements  that  are 
needed  for  addressing  specific  challenges  in  smartphone  clouds  (Section  3.1),  and  the 
relationships  among  those  elements  (Section  3.2).  We  formalize  the  model  and  give  the 
rules  of  access  (Sections  3.3  and  3.4).  The  smartphone  cloud  system  is  very  dynamic 
and  allows  frequent  updates  to  its  RBAC  relations.  Using  traditional  RBAC  relations  to 
control  delegation  in  such  environments  is  of  limited  advantage  because  of  the  result¬ 
ing  inconsistencies  in  role  hierarchy.  We  adapt  the  notion  of  administrative  scope  to  re¬ 
solve  dynamically  any  inconsistency  involved  in  controlling  delegations  (Section  3.5). 
Finally,  we  propose  algorithms  to  perform  trust-based  delegation,  including  chained 
delegation  (Section  4). 


2  Related  Work 


Role-Based  Access  Control  (RBAC)  is  used  extensively  within  organizations  for  ad¬ 
ministering  and  managing  privileges  and  is  often  considered  the  de-facto  standard  for 
access  control. 

While  the  advantages  of  RBAC  are  numerous,  researchers  are  increasingly  identi¬ 
fying  limitations  in  the  model  for  newer  and  emerging  applications.  The  biggest  limita¬ 
tion  is  the  lack  of  support  for  delegation  in  the  standard  RBAC  model  and  the  failure  to 
support  dynamic  adaptation  of  access  control  policies  based  on  changing  needs.  Many 
researchers  have  extended  RBAC  to  support  delegation  [8-14];  however  these  mod¬ 
els  fail  to  support  the  need  for  ad  hoc  authorization  and  ad  hoc  delegation  and  thus 
cannot  readily  be  adapted  to  the  cloud  environment.  Researchers  have  also  proposed 
Credential-based  or  Attribute-based  access  control  models  [15, 16]  to  address  the  chal¬ 
lenges  of  unknown  users  in  access  control.  Unfortunately,  these  models  do  not  allow 
access  control  decisions  to  be  dynamically  updated  or  revoked  based  on  the  history  of 
the  requester,  or  based  on  changing  requirements  of  the  requester. 
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Fig.  2.  Schematic  overview  of  the  new  access  control  model  for  clouds 


Recently,  researchers  have  proposed  the  notion  of  risk- adaptable  access  control 
models  [17-19]  and  trust-based  access  control  models  [5,20,21]  to  facilitate  dynamic 
adaptation  of  access  control  policies  based  on  operational  needs  and  situational  aware¬ 
ness.  A  recent  work  [22]  combines  these  two  philosophies  into  one  comprehensive 
model.  However,  none  of  these  works  address  the  problem  of  delegation  in  mobile 
cloud  systems.  Nonetheless,  these  approaches  look  promising  and  form  the  basis  of  the 
current  model. 


3  Formal  access  control  model  with  delegation 


The  proposed  trust-based  access  control  model  is  defined  in  terms  of  a  set  of  elements 
and  relations  among  those  elements  with  trust-based  constraints  defined  on  these  rela¬ 
tions.  We  use  a  modified  graph-theoretic  approach  similar  to  the  one  proposed  by  Chen 
and  Crampton  [23]  to  express  the  model  semantics.  This  model  is  designed  to  integrate 
delegation  and  revocation,  with  revocation  being  the  reverse  process  of  delegation.  The 
model  offers  the  possibility  to  perform  a  single-step  as  well  as  a  multi-step  delegation 
and  revocation.  It  enables  both  roles  and  permissions  to  be  delegated.  Fig.  2  provides 
a  schematic  overview  of  the  proposed  model.  We  use  the  access  control  scenario  from 
Figure  1  to  exemplify  the  model. 
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3.1  Model  elements 


The  model  elements  are  of  the  following  types:  user,  user  properties,  role,  object,  ac¬ 
tion,  permissions,  constraints,  trust Jevel,  session  Jnstance,  session  Jype,  session,  and 
session-history.  The  corresponding  element  sets  are  represented  by  the  symbols  U, 
Prop,  R,  O,  Act,  P,  Const,  Sj,  Sj,  S,  Sh- 

In  this  model,  roles  are  separated  into  two  broad  classes:  regular  roles  and  delegat- 
able  roles.  A  user  cannot  delegate  permissions  assigned  to  a  regular  role,  while  permis¬ 
sions  assigned  to  a  delegatable  role  can  be  delegated.  The  cloud  system  is  responsible 
for  creating  each  regular  role,  while  each  delegatable  role  is  created  and  owned  by  an 
individual  user.  Therefore,  a  regular  role  is  a  durable  role,  while  a  delegatable  role  is 
temporary,  created  and  deleted  at  the  user’s  discretion.  In  the  cloud  system,  each  user 
owns  a  set  of  delegatable  roles  that  form  a  role  hierarchy  determined  by  the  user.  All 
user  assignment  to  regular  roles  relations  and  all  permission  assignment  to  regular  roles 
relations  are  managed  by  the  cloud  system,  while  each  individual  user  is  responsible  for 
managing  all  user  assignment  to  delegatable  roles  relations  and  all  permission  assign¬ 
ment  to  delegatable  roles  relations. 

user  A  user  m  €  t/  is  a  human  being,  a  device,  an  organization  or  any  active  agent  run¬ 
ning  on  behalf  of  these.  Three  categories  of  users  can  be  found  in  the  cloud,  namely, 
tenant,  a  tenant-as-provider,  and  a  provider.  A  tenant  is  a  user  that  is  receiving  reg¬ 
ular  services  offered  in  the  cloud,  while  a  tenant-as-provider  is  a  cloud  user  that 
is  receiving  regular  services  as  well  as  offering  regular  services.  The  last  category, 
provider,  refers  to  the  cloud  provider.  To  understand  these  notions,  let  consider  the 
example  of  Netflix  that  uses  Amazon’s  cloud.  A  Netflix  subscriber  is  a  tenant,  while 
Netflix  is  the  tenant-as-provider.  The  provider  in  this  case  is  Amazon’s  cloud. 
user_properties  Each  user  u  has  a  certain  set  of  properties  called  user  properties. 

The  set  Prop  =  {j^eu  A  user  can  manifest  any  subset  of  (i-C-.  Pu  €  2'^“) 
in  a  particular  session.  User  properties  are  used  in  our  model  to  compute  trust  levels 
of  users  (see  later  in  the  list).  Some  examples  of  elements  of  user_properties  are: 
user  credentials,  public  key  certificates,  and  membership  in  groups, 
role  The  concept  of  role  is  the  same  as  in  the  RBAC  model.  A  role  r  G  R  is  a  job 
function  with  some  associated  semantics  regarding  the  responsibilities  conferred  to 
the  user.  A  user  assigned  to  a  role  specifies  the  operational  needs  of  the  cloud.  The 
set  of  roles  R  can  be  further  subdivided  into  six  disjoint  subsets  as  follows: 

1.  TENANT-REGULAR-ROLE  (TRR)  -  A  set  of  job  functions  that  are  relevant 
for  receiving  regular  services.  Eor  example,  the  human  user  in  our  scenario  can 
be  an  elite  member  with  the  mobile  wallet  service  provider  that  bestows  him 
with  certain  privileges.  In  this  case  “elite  member’’  will  be  an  example  of  a 
tenant-regular  role. 

2.  TENANT-DELEGATABLE-ROLE  (T  DR)  -  A  set  of  job  functions  that  are  rel¬ 
evant  for  delegating  services.  Going  back  to  our  earlier  scenario,  the  VAC  ins¬ 
tance  working  on  behalf  of  the  user  to  purchase  tickets  needs  to  have  permis¬ 
sion  at  the  MobWC  to  use  the  user’s  wallet.  Thus,  a  role  such  as  “wallet  user 
for  ticket  purchase”  which  the  VAC  needs  to  assume  to  execute  the  operation 
will  be  an  example  of  tenant-delegatable-role. 
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3.  TENANT-AS-PROVIDER-REGULAR-ROLE  (TPRR)  -  A  set  of  job  func¬ 
tions  that  are  relevant  for  receiving  regular  services  as  well  as  offering  regular 
services.  The  NavC  cloud  is  a  provider  of  navigation  services.  It  uses  the  infras¬ 
tructure  cloud  to  provide  some  of  its  services  (such  as  the  computation  needed 
for  the  navigation).  As  a  result,  we  will  have  a  tenant-as-provider-regular-role 
’’navigation  computation”  at  the  infrastructure  cloud. 

4.  TENANT-AS-PROVIDER-DELEGATABLE-ROLE  (TPDR)  -  A  set  of  job 
functions  that  are  relevant  for  receiving  as  well  as  offering  delegation  services. 
The  VAC  will  have  a  tenant-as-provider-delegatable  role  “make  ticket  reserva¬ 
tion”  that  will  allow  it  to  delegate  different  components  of  the  ticket  reserva¬ 
tion. 

5.  PROVIDER-REGULAR-ROLE  (PRR)  -  A  set  of  job  functions  that  are  rele¬ 
vant  for  providing  regular  services.  The  instance  of  MobWC  that  will  access 
the  user’s  wallet  needs  to  have  permission  to  debit  the  wallet  to  provide  the  ser¬ 
vice.  Thus,  an  example  of  this  role  will  be  “debit  user  wallet”  that  the  instance 
of  MobWC  needs  to  acquire  for  this  task. 

6.  PROVIDER-DELEGATABLE-ROLE  (PDR)  -  A  set  of  job  functions  that  are 
relevant  for  providing  delegation  services.  Assume  that  the  TktC  offers  the  tick¬ 
eting  service  by  using  a  database  provider  cloud  to  keep  record  of  the  transac¬ 
tion.  Thus,  an  instance  of  the  TktC  that  is  performing  the  ticketing  operation  for 
the  current  user  needs  to  delegate  the  record  update  operation  to  the  database 
provider.  A  “decrement  available  seats”  role  will  be  an  example  of  a  provider- 
delegatable-role  in  this  scenario. 

object  An  object  o  €  is  a  data  resource  as  well  as  a  system  resource.  It  can  be  thought 
of  as  a  container  that  contains  information.  The  set  O  (OBJECTS)  is  partitioned 
into  three  subsets: 

1.  TENANT-OBJECTS  {TO)  -  Objects  from  this  set  are  accessed  when  some 
services  are  needed.  An  example  is  the  user’s  wallet  at  the  MobWC. 

2.  TENANT-AS-PROVIDER-OBJECTS  {TPO)  -  Objects  from  this  set  are  ac¬ 
cessed  for  receiving  as  well  as  providing  services.  An  example  is  the  database 
used  by  the  TktC  to  keep  record  of  transactions. 

3.  PROVIDER-OBJECTS  {PO)  -  Objects  in  this  set  are  accessed  purely  for  pro¬ 
viding  services.  Examples  include  objects  used  by  the  infrastructure  cloud  such 
as  network  objects. 

action  An  action  a  e  A  is  an  executable  image  of  a  program  that  operates  on  some 
object.  The  set  A  (ACTIONS)  may  have  three  subtypes  ACTIONS: 

1.  TENANT- ACTIONS  (TA)  -  This  set  of  actions  act  on  objects  from  the  set 
TENANT-OBJECTS.  An  example  is  “debit  wallet”. 

2.  TENANT- AS -PROVIDER- ACTIONS  {T PA)  -  This  set  is  comprised  of  actions 
that  operate  on  elements  of  TENANT-AS-PROVIDER-OBJECTS.  An  example 
is  “update  database”. 

3.  PROVIDER- ACTIONS  (PA)  -  This  set  is  comprised  of  actions  that  operate  on 
elements  of  PROVIDER-OBJECTS.  An  example  is  “perform  read  on  disk”. 

permission  A  permission  p  €  P  is  an  authorization  to  perform  a  certain  task  within  the 
system.  A  permission  is  assigned  to  a  role.  The  set  P  (PERMISSIONS)  is  parti¬ 
tioned  into  three  subsets  as  follows: 
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1.  TENANT-PERMISSIONS  (TP)  -  The  set  of  all  ordered  pairs  {TO,  TA)  where 

TO  G  TENANT-OBJECTS  and  TA  G  TENANT- ACTIONS;  that  is, 

J’p  _  '2T0XTA 

2.  TENANT- AS-PROVIDER-PERMISSIONS  {TPP)  -  The  set  of  all  ordered  pairs 

{TPO,  TPA)  where  TPO  G  TENANT- AS -PROVIDER-OBJECTS  and 

TPA  G  TENANT-AS-PROVIDER-ACTIONS;  that  is, 

Ypp _ 

3.  PROVIDER-PERMISSIONS  (PP)  -The  set  of  all  ordered  pairs  {PO,PA)  where 

PO  G  PROVIDER-OBJECTS  and  PA  G  PROVIDER- ACTIONS;  that  is, 

pp  _  2^POXPA 

trust  Jevel  A  tmstJevel  G  ^  is  a  real  number  between  0  and  1,  with  0  being  the  lowest 
level  of  trustworthiness  and  1  the  highest  and  intuitively  encodes  the  security  risk 
of  the  access  decision.  The  larger  the  value  of  the  trustJevel  the  less  risky  it  is  to 
grant  access  to  the  user.  A  user  u  associated  with  a  role  r  at  some  instant  of  time  has 
a  trustJevel.  The  function  3P{u,r)  gives  the  trustJevel  of  the  corresponding  user 
associated  with  the  role  r. 

role -trust  .range  A  role_trust_range  is  an  interval  1]  that  is  associated  with  roles. 

The  role_trust_range  indirectly  encodes  the  situational  factors  under  which  the  ac¬ 
cess  decision  is  made.  Each  role  r  G  P  is  associated  with  a  role_trust_range  that 
gives  the  minimum  trust  value  rtmin  required  for  a  user  to  be  assigned  to  the  corre¬ 
sponding  role.  The  function  ^{r)  returns  the  value  rtmin  for  the  given  role  r. 

permission_trust_range  A  permission_trust_range  is  an  interval  \ptmim  1]  that  is  asso¬ 
ciated  with  permissions.  Each  permission  Perm  G  P  is  associated  with  a  permis- 
sion_trust_range  that  gives  the  minimum  trust  value  ptmin  required  by  a  role  to  be 
assigned  the  corresponding  permission.  The  function  ^ {Perm)  returns  the  value 
ptmin  for  the  given  permission  Perm. 

constraint  A  constraint  G  Cons  is  defined  as  a  predicate  which  when  applied  to  a 
relation  between  two  elements  returns  a  value  of  “acceptable”  (True  or  1)  or  “not- 
acceptable”  (Ealse  or  0).  Constraints  can  be  viewed  as  conditions  imposed  on  the 
relationships  and  assignments  and  encode  the  situational  factors  under  which  access 
decisions  need  to  be  made. 

sessionJnstance  A  sessionJnstance  G  5/  is  a  Jogin’  instance  of  an  user.  It  is  the  set 
of  roles  activated  by  the  user  in  that  login  instance.  A  user  can  instantiate  mul¬ 
tiple  logins  thereby  initiating  multiple  sessionJnstances  at  the  same  time.  A  ses¬ 
sionJnstance  is  uniquely  identified  by  a  system  generated  id. 

sessionJype  A  sessionJnstance  is  identified  with  a  type  that  is  defined  by  the  set  of 
user.properties  manifested  in  that  sessionJnstance  by  the  user.  Eor  a  sessionJnstance 
Us  activated  by  a  user  u  with  set  of  properties  Propu  (Propu  C  the  sessionJype 
is  propu-  Eormally,  the  set  Sj  =  2^’’°’’ . 

session  A  session  G  5  is  identified  by  a  sessionJnstance  with  a  sessionJype.  A  session 
with  sessionJnstance  Us  and  type  Propu  is  denoted  by  the  symbol  u^‘’P'‘  .  Eormally, 

S  =  Si  X  St- 

session  Jiistory  A  session_history  G  5//  is  a  set  of  information  regarding  the  user’s 
roles,  behavior  and  trust  levels  in  a  previous  use  of  a  session  of  that  type. 
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3.2  User-role  and  permission-role  assignment 

We  propose  a  graph  theoretic  semantics  for  our  model.  An  authorization  graph  is  de¬ 
fined  in  terms  of  a  set  V  of  vertices  and  a  set  E  of  edges.  The  set  of  vertices  V  = 
U  U  TRRUTDR  U  TPRRUTPDRU  PRRU  PDRU  TPUTPPU  PP  corresponds  to  the 
entities  users,  tenant-regular-roles,  tenant-delegatable-roles,  tenant-as-provider-regular- 
roles,  tenant-as-provider-delegatable-roles,  provider-regular-roles,  provider-delegatable- 
roles,  tenant-permissions,  tenant-as-providers-permissions  and  provider-permissions  re¬ 
spectively.  The  set  of  edges  E  =  URRA  U  UDRA  U  PRRA  U  PDRA  U  RREIa  U  DRHa  U 
RRHuUDRHu  corresponds  to  the  different  relationships  between  the  model’s  entities. 

We  now  define  some  relationships  with  roles  that  form  the  building  block  for  the 
access  control  model,  as  follows: 

Definition  1.  User-Regular-Role  Assignment  (URRA )  =  (U  xT RR)  U  (U  xT PRR)  U 
(U  X  PRR)  is  a  many-to-many  relationship  that  provides  the  regular  roles  to  which 
dijferent  users  can  be  assigned  in  the  cloud.  It  is  represented  as  a  pair  of  user-regular- 
roles. 

Definition  2.  User-Delegatable-Role  Assignment  (UDRA )  =  (U  xT DR)  (J{U  xT PDR) 
U(U  X  PDR)  is  a  many-to-many  relationship  identifying  delegatable  roles  to  which  dif¬ 
ferent  users  can  be  assigned  in  the  cloud.  This  relationship  is  represented  as  a  pair  of 
user-delegatable-roles. 

Definition  3.  Permission-Regular-Role  Assignment  (PRRA )  =  (TRR  xTP)U  (TPRR  x 
TPP)  U  (PRR  X  PP)  is  a  many-to-many  relationship  providing  the  set  of  permission- 
regular-roles  that  indicate  to  regular  roles  which  permissions  they  are  allowed  to  ac¬ 
quire. 

Definition  4.  Permission-Delegatable-Role  Assignment  (PDRA)  =  (TDR  xTP)U 
(TPDR  X  TPP)  U  (PDR  x  PP)  is  a  many-to-many  relationship  providing  the  set  of 
permission-delegatable-roles  identifying  the  permissions  for  which  delegatable  roles 
are  authorized. 

The  role-hierarchy  defines  parent-child  relationships  between  different  roles.  This 
allows  for  easy  administration  of  roles  by  reducing  the  number  of  explicit  assignments 
in  the  URRA,  UDRA,  PRRA,  and  PDRA  relations.  Regular  roles  are  organized  in  a 
Regular-Role-Hierarchy  while  delegatable  roles  are  organized  in  a  Delegatable-Role- 
Hierarchy  with  the  two  hierarchies  being  disjoint.  We  define  the  two  hierarchies  as 
follows: 

Definition  5.  The  Role -hierarchy  (RH)  =  91  x  {a,u},  is  a  partial  order  on  the  set  of 
roles  where  91  =  ((TRR  x  TRR)  U  (TPRR  x  TPRR)  U  (PRR  x  PRR))  in  case  role  is  a 
regular  role.  In  the  same  case  RH  is  written  RRH  to  represent  a  regular  role-hierarchy. 
When  considering  the  case  when  role  is  a  delegatable  role,  then  (91  =  ((TDR  x  TDR)  U 
(TPDR  X  TPDR)  U  (PDR  x  PDR)),  and  RH  becomes  DRH  to  represent  a  delegatable 
role-hierarchy.  The  set  {a,u}  can  be  considered  as  one  of  these  : 

-  the  role-activation  hierarchy 
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-  the  permission-usage  hierarchy 

Let  <a  denote  the  reflexive  transitive  closure  of  91^  while  <„  denotes  the  reflexive 
transitive  closure  of  Then  role-activation  hierarchy  and  permission-usage  hierarchy 
are  defined  as  follows. 

Definition  6.  Role-activation  hierarchy  (3ia)  =  €  91}  is  a  subset  of3i 

such  that  a  user  u  may  activate  a  role  r  in  a  sessionJnstance  if  there  exists  a  role  r' 
such  that  {u,r''\  €  URRA  and  r  <a  r'  if  r  and  d  are  regular  roles,  or  {Ujf'}  €  UDRA 
and  r  <a  r'  when  r  and  d  are  delegatable  roles. 

Definition  7.  Permission  usage  hierarchy  (3iu)  =  ■  {t',r' ,u)  €  91}  such  that  a 

user  is  authorized  for  permission  p  if  there  exists  roles  r,r'  such  that  u  may  activate  r', 
with  (p,  r)  €  PRRA  and  r  <„  r'  in  the  case  r,  P  are  regular  roles,  or  with  {p,  r)  €  PDRA 
and  r  <„  P  when  r,  P  are  delegatable  roles.  In  the  first  case  91„  becomes  RRH^,  while  it 
becomes  DRHu  when  roles  are  delegatable. 

3.3  Evaluating  access  requests 

The  cloud  security  administrator  assigns  trust  constraints  in  the  form  of  a  corresponding 
trust  interval  to  roles,  permissions,  and  other  associations  between  entities  based  on 
different  characteristics  of  each  model.  Note  that  in  the  cloud  structure,  users,  tenants 
or  providers  of  the  senior  role  can  perform  the  same  set  of  duties  as  its  junior  role;  hence 
an  entity  who  will  be  assigned  to  the  senior  role  require  more  trustworthiness  than  the 
entity  who  will  be  assigned  to  junior  role  only.  Based  on  this  observation,  when  we 
introduce  the  notion  of  trust  value,  we  assume  that  the  trust  value  of  the  senior  role 
always  dominates  the  trust  values  of  its  junior  roles. 

We  have  previously  proposed  the  notions  of  activation  path,  usage  path  and  access 
path  in  [6]  to  evaluate  if  an  access  control  request  should  be  denied  or  granted  according 
to  the  current  policy.  We  adapt  and  extend  these  notions  here  to  determine  access  request 
for  mobile  smartphone  clouds. 

Definition  8.  An  activation  path  (or  act-path)  between  two  nodes  vi  and  v„  in  the  au¬ 
thorization  graph  is  a  sequence  of  vertices  €  £  such  that  either  (vi,V2)  € 

URRA  and  (v,_i,  v,)  G  RRHa  for  i  =  3, . . .  ,n  on  a  regular-role  hierarchy  or  (vi,  V2)  G 
UDRA  and  ( v,_  1 ,  v,)  €  DRHa  for  i  =  3, . . .  ,n  on  a  delegatable -role  hierarchy. 

Definition  9.  A  usage  path  (or  u-path)  between  two  nodes  v\  and  Vn  in  the  authoriza¬ 
tion  graph  is  a  sequence  of  vertices  vi, . . . ,  v„  €  £  such  that  either  (v,,  v,+i)  €  RRH^for 
/  =  1 , . . . , n  —  2,  and  (v„_  1 ,  v„)  €  PRRA  on  a  regular-role  hierarchy  or  (v,,  )  G  DRHu 

for  i  =  1 , . . . ,  n  —  2,  and  ( v„_  1 ,  v„ )  €  PDRA  on  a  delegatable-role  hierarchy. 

Definition  10.  An  access  path  (or  acs-path)  between  two  nodes  v\  and  v„  in  the  autho¬ 
rization  graph  is  a  sequence  of  vertices  vi, . . .  ,v„,  such  that  {v\,vP)  is  an  act-path,  and 
(vk,v„)  is  an  u-path. 

Based  on  these  definitions  of  usage  path,  access  path  and  activations  we  propose 
three  different  access  control  models,  namely,  the  standard  model,  the  strong  model 
and  the  weak  model.  The  models  differ  with  respect  to  the  trust  constraints  that  must  be 
satisfied  by  the  entities  for  the  authorization  to  be  successful. 


9 


3.4  The  standard  model 


In  the  standard  model,  individual  entities  are  associated  with  trust  values  and  describe 
how  much  the  user  is  trusted  to  perform  a  specific  role.  The  role_trust_range  associ¬ 
ated  with  a  tenant  role,  a  tenant-as-provider  role  or  a  provider  role  specifies  the  mini¬ 
mum  trust  level  with  respect  to  that  role  that  the  user  has  to  acquire  in  order  to  activate 
the  corresponding  role.  Similarly,  the  permission_trust_range  associated  with  a  tenant- 
permission,  tenant-as-provider-permission  or  provider-permission  specifies  the  mini¬ 
mum  trust  level  with  respect  to  the  current  role  of  the  user,  that  needs  to  be  acquired  in 
order  to  invoke  these  permission. 

Let  the  trust  values  for  the  user  be  specified  by  a  function  :  {{Uh  X  Rh)  U  {Ud  X 
f^d))  t  G  ^  and  the  trust  ranges  for  role  and  permission  by  functions  .if  :  (/?  U  P)  —> 

-  For  u  G  U,r  G  R,  3^{u,r)  denotes  the  trust  value  of  u  with  respect  to  r; 

-  For  r  G  R,  -Sf(r)  denotes  the  trust  interval  in  which  r  is  active; 

-  For  p  G  P,  .if  (p)  denotes  the  trust  interval  in  which  p  is  active. 

For  any  path  vi, . . . ,  v„  in  the  graph  G=  {V,E,  SP  where  E  =  U  RRAUU  DRAU 
PRRAU PDRAU RRHaU DRHaU RRHuU DRHu,  we  write  .if(v2, . . . , v„)  =  .if(v2,  v„)  C 

n 

^  to  denote  P|.if(v,).  In  other  words,  .if(v2,v„)  is  the  trust  interval  in  which  every 

i=2 

vertex  Vi  G  RU P  is  enabled. 

Authorization  in  the  Standard  Model  is  based  on  the  policy  decision  point  making 
the  following  three  determinations  corresponding  to  the  requested  access: 

1.  Is  the  role  that  the  user  needs  to  activate  in  the  current  session  in  order  to  acquire 
the  desired  permission,  authorized  for  the  permission? 

2.  Can  the  user  activate  the  corresponding  role? 

3.  Is  the  user  authorized  for  the  desired  permission? 

If  the  policy  decision  point  makes  a  positive  determination  for  all  these  conditions  a 
decision  to  allow  the  access  is  made.  These  three  determinations  are  made  based  on  the 
following  propositions. 

Proposition  1.  A  role  vi  G  R  is  authorized  for  permission  Vn  G  P  if  and  only  if  there 
exists  an  u-path  vi,  V2, . . . ,  v„  and  .if  (vi)  C  .if(vi ,  v„). 

Proposition  2.  A  user  v\  GU  may  activate  role  Vn  G  R  if  and  only  if  there  exists  an 
act-path  vi,V2,. . .  ,v„  and  ^{vi,V2)  G  Aflvz)- 

Proposition  3.  A  user  v\  GU  is  authorized  for  permission  v„  G  P  if  and  only  if  there 
exists  an  acs-path  vi , V2, . . . , Vjt, . . . , v„  such  that  VkG  R  for  some  k,  ,Vk  is  an  act- 

path,  Vk,---,Vn  is  a  u-path,  vi  can  activate  Vk,  and  Vk  is  authorized  for  v„. 
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3.5  Controlling  delegation 

A  delegation  operation  temporarily  changes  the  access  control  state  so  as  to  allow  the 
delegatee  to  use  the  initial  user’s  access  privileges.  Delegation  operations  are  classified 
into  two  kinds:  grant  operations  and  transfer  operations  [8].  Grant  operations  are  de¬ 
fined  by  grant  delegation  models  and  allow  the  delegated  access  rights  to  be  available  to 
both  the  delegator  and  the  delegatee,  after  a  successful  completion  of  a  delegation  oper¬ 
ation.  Transfer  operations,  on  the  other  hand,  are  defined  by  transfer  delegation  models 
to  allow  the  delegated  access  right  to  be  acquired  by  the  delegatee,  while  preventing 
the  delegator  from  continuing  to  use  the  delegated  access  right.  Most  works  done  in 
this  field  focus  on  grant  operation  [8,9, 11-14].  Crampton  and  Khambhammettu  first 
introduced  the  notion  of  transfer  operation  in  [10]. 

Designing  a  mechanism  for  delegation  control  involves  specifying  under  which  con¬ 
dition  a  delegation  operation  is  permitted.  This  requires  resolving,  in  order,  the  follow¬ 
ing  two  issues:  (1)  Determine  whether  or  not  a  given  user  is  authorized  to  delegate  a  role 
or  permission  available  to  the  user.  (2)  Determine  whether  a  given  role  or  permission 
can  be  delegated  to  a  user. 

Relations  have  been  the  main  way  to  control  delegation  [9, 13, 14]  in  role-based 
systems.  Two  principal  relations,  can^delegate  and  can^receive,  are  used  for  control¬ 
ling  delegation.  Relations  are  suited  to  be  used  in  a  RBAC  system  but  only  where  RBAC 
relations  remain  static.  However,  in  a  cloud  system,  RBAC  relations,  such  the  role  hi¬ 
erarchy,  are  frequently  updated.  This  situation  can  generate  serious  inconsistencies  in 
relations  can_delegate  and  can_receive  that  specify  respectively,  who  is  authorized  to 
delegate  access  rights,  and  who  is  allowed  to  receive  delegated  access  rights.  For  this 
reason,  we  have  opted  to  use  the  concept  of  administrative  scope  [24]  to  deal  with 
delegation  control.  Administrative  scope  is  a  concept  borrowed  from  RHA  family  of 
administrative  models,  and  is  defined  as  follows  [24]. 

Definition  11.  Let  r  G  R.  We  define  a{r)  the  administrative  scope  of  a  role  r  as  the  set 
O'(r)  =  {fi}  such  that  if  a  role  fi  G  O’(r)  then  in  the  graph  formed  by  the  role  hierarchy, 
any  path  starting  at  fi  passes  through  r. 

Definition  12.  Let  s  be  a  session  activated  by  a  user  u.  We  define  cj(i)  the  administra¬ 
tive  scope  of  a  session  s  as  (7(s)  =  Ur{Ei<7(r).  The  idea  expressed  by  this  definition  is 
that  the  administrative  scope  of  a  session  is  simply  the  union  of  administrative  scopes 
of  all  roles  activated  in  the  session  s  by  the  user  u. 

The  concept  of  administrative  scope  provides  us  with  a  way  to  divide  a  role  hi¬ 
erarchy  graph  into  sub-hierarchies  that  form  a  natural  unit  of  administration  for  the 
role  r.  Two  approaches  are  the  most  favored  for  performing  role-based  administration, 
ARBAC91  and  administrative  scope.  Among  these  two  approaches,  administrative  scope 
is  found  to  be  a  more  flexible  approach  [24].  This  quality  makes  it  suitable  for  role- 
based  delegation  in  a  highly  dynamic  environment  that  is  the  cloud  system. 

Using  administrative  scope,  a  user  u  is  allowed  to  delegate  a  role  r  only  if  r  €  <t(s), 
the  administrative  scope  of  the  users  session.  This  limits  the  user  to  delegate  only  roles 
that  are  within  his  administrative  scope.  Administrative  scope  can  be  used  to  regulate 
who  can  receive  a  delegation.  A  user  v  is  authorized  to  receive  a  delegation  of  a  role 
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r  from  user  u  if  for  all  r'  <  r  such  that  r'  ^  O’(s),  there  exists  r"  such  that  r'  <  r"  and 
(v,  r')  G  UDA.  In  order  words,  the  delegatee  v  is  authorized  to  receive  the  delegation  of 
a  role  r  if  v  is  already  authorized  for  all  role  r'  <  r.  In  order  for  the  delegatee  to  receive 
a  delegation,  the  idea  is  to  require  him  to  be  already  assigned  to  any  roles  outside  the 
delegators  administrative  scope  that  the  delegatee  will  inherit  by  successfully  receiving 
the  delegation. 


4  Chaining  Delegation  and  Transfer 

A  user  that  has  previously  received  some  access  rights  through  a  delegation  process 
may  decide  to  further  delegate  those  rights.  This  can  result  in  what  can  be  called  a 
chained  delegation.  In  this  delegation  chain  the  trustworthiness  of  users  is  used  by  each 
node  as  a  factor  to  decide  about  the  level  of  delegation.  These  trust  values  form  a  trust 
chain.  We  use  the  notion  of  trust  graph  expressed  in  [25]  to  formalize  the  notion  of 
trust  chain  in  a  given  context.  A  trust  graph  T  —  {N,E)  is  a  directed  acyclic  graph  that 
is  defined  in  terms  of  a  set  N  of  nodes  and  a  set  E  of  edges.  Nodes  represent  entities 
in  the  delegation  chain,  while  edges  represent  trust  relationship  between  these  entities. 
These  entities  could  be  either  users  or  roles  respectively  for  user  delegation  and  role 
delegation. 

Using  trust  graphs  node  n,  trusting  node  nj  can  be  represented  by  (ni,nj).  The  degree 
to  which  an  entity  n,  trusts  rij  is  represented  by  a  weight  denoted  by  w{n  i,nj),  0  < 
w{ni,nj)  <  1,  on  the  edge  (nj,nj).  In  order  to  control  the  propagation  of  the  access  right 
during  a  delegation  process,  every  entity  puts  a  constraint  on  its  trust  relationship.  This 
trust  constraint  is  denoted  by  c(n, ■,«;■)  where  0  <  c{ni,nj)  <  1.  Access  rights  can  be 
propagated  only  if  c{ni,nj)  <  w{ni,nj).  This  implies  that  delegation  cannot  be  carried 
along  every  edge  of  the  trust  graph.  Therefore  identifying  valid  paths  to  carry  on  a 
delegation  becomes  a  challenging  problem. 


Fig.  3.  Example  of  a  trust  graph 


We  consider  the  trust  graph  represented  in  Fig.  3.  The  numbers  that  are  within  boxes 
associated  with  the  edges  denote  the  trust  values  on  the  corresponding  edges  of  the 
graph  while  the  numbers  that  are  not  inside  boxes  denote  the  trust  constraints.  Assume 
that  the  entity  J  desires  to  identify  all  the  valid  paths  it  can  use  to  delegate  some  access 
rights  to  entity  K.  Using  the  trust  values  and  the  trust  constraints,  the  first  challenge  is  to 
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determine  all  valid  paths  and  thereafter  to  compute  the  transitive  trust  value  for  each  of 
the  found  valid  paths  from  J  to  K.  We  use  three  operators  on  trust  values  -  a  comparison 
operator  to  compare  the  trust  value  and  the  trust  constraint,  a  parallel  operator  to  find 
the  minimum  of  two  trust  values,  and  a  sequential  operator  that  gives  the  product  of 
two  trust  values. 

Definition  13.  Comparison  Operator  0  :  [0,1]  X  [0,1]  —>-0,1  is  a  binary  operation 
whose  input  is  a  trust  value  and  a  trust  constraint,  and  that  returns  1  when  the  trust 
value  is  greater  or  equal  to  the  trust  constraint.  Otherwise,  the  operator  returns  0. 

Definition  14.  Parallel  Operator,  denoted  0  :  [0, 1]  x  [0, 1]  — >■  [0, 1],  is  a  binary  oper¬ 
ator  whose  inputs  are  two  trust  values,  and  that  returns  the  minimum  of  the  two  trust 
values. 

Definition  15.  Sequential  Operator,  denoted  ®  '.  [0, 1]  x  [0, 1]  — >  [0, 1],  is  a  binary  op¬ 
erator  whose  inputs  are  two  trust  values,  and  that  returns  the  product  of  these  two  trust 
values. 

The  comparison  operator  is  used  to  identify  all  the  valid  paths  in  a  trust  graph.  Those 
valid  paths  are  the  ones  able  to  carry  on  the  delegation  from  J  to  K.  The  checking  of 
valid  paths  may  return  either  multiple  valid  paths,  or  a  single  valid  path.  In  either  case, 
we  need  to  compute  the  transitive  trust  value.  The  parallel  operator  is  used  to  compute 
the  transitive  trust  value  in  case  of  multiple  valid  paths  while  the  sequential  operator  is 
used  for  the  same  purpose  but  in  case  of  a  single  valid  path. 

These  operators  are  used  within  algorithm  1  to  find  the  transitive  trust  value.  The 
algorithm  works  as  follows.  Using  a  set  of  edges  of  the  trust  graph  given  as  input, 
the  algorithm  uses  the  comparison  operator  on  each  pair  of  edges  that  form  an  arc  to 
compare  its  trust  values  to  its  trust  constraint.  All  arcs  whose  trust  value  is  at  least  equal 
to  the  trust  constraint  are  retained.  If  after  being  linked  those  arcs  form  one  or  more 
paths  from  the  source  node  to  the  destination  node,  then  those  paths  are  considered  to 
be  the  valid  paths.  If  the  algorithm  find  multiple  valid  paths,  it  uses  the  parallel  operator 
to  find  the  path  with  the  minimum  transitive  trust  value.  Otherwise,  the  algorithm  uses 
the  sequential  operator  to  return  the  transitive  trust  value  of  the  unique  path.  In  case  of 
multiple  valid  paths,  we  made  the  design  decision  to  choose  the  path  with  the  minimum 
transitive  trust  value  in  order  to  be  more  conservative  and  more  protective.  Choosing  the 
path  with  a  maximum  transitive  trust  value  is  also  a  valid  choice,  but  is  not  considered 
in  this  work. 

To  see  how  the  propagation  of  delegation  works,  we  use  the  trust  graph  in  Fig.  3 
and  execute  our  algorithm  in  order  to  find  the  transitive  trust  value  from  node  J  to 
node  K.  Before  running  the  algorithm  on  the  given  graph,  a  processing  step  is  nec¬ 
essary.  This  preprocessing  involves  doing  a  Depth-First  Search  on  the  graph  in  or¬ 
der  to  collect  all  the  arcs  from  nodes  J  to  K.  The  result  of  the  DFS  is  as  follows. 
DFS{G)  =  {J,C),{C,D),{D,K),{C,B),{B,K),{J,A),{A,D),{A,B).  This  list  of  edges 
is  provided  to  the  algorithm  as  input. 

Given  the  list  of  arcs,  we  run  the  algorithm  as  follows. 

-  (J,C) :  w(J,C)  0  c(J,C)  =  0.6  0  0.6  =  1  valid_paths  =  {(J,C)} 
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Algorithm  1  Algorithm  to  identify  all  valid  paths  for  delegation  propagation 

Input:  edges  , . . . , 

Output:  set  of  valid  paths  and  transitive  trust  on  the  valid  paths 
valid ^paths  •<—  {} 
for  all  i  :  1  <  i  <  n  do 
compjrusti  ■4—  0 

end  for 

for  all  / :  1  <  1  <  «  do 

comptJrusti  4—  w{ei)Qc{ei) 
if  compjrusti  =  1  then 
valid.paths  ■4—  (ei) 

end  if 
end  for 

if  |Valid_paths|  >  1  then 

Let  valid  .paths  =  {(ni  ,«2j  ?  •  •  ■  );  {^i  5^22 ,  •  •  • 

min  4—  1 ; 

for  all  / :  1  <  /  <  7  do 
transJrustj  4—  0 

end  for 

for  all  / :  1  <  /  <  7  do 

for  all  1 :  1  </<(/:—  2)  do 

transJrusti  4—  transJrusti  +H'(n,-,rt,+i)0H'(«,--|-i).rt,'-|-2) 

end  for 
end  for 

for  all  / :  1  <  /  <  7  do 

min  4—  mm0  {transjrust)i 

end  for 
end  if 

if  I  valid. paths  \  =  1  then 

Let  valid. paths  =  {wj ,n2, . . . 

transJrusti  ^  0 

for  all  /:  1  </<(/:  —  2)  do 

transJrusti  ^  transJrusti  x  ®  ,rt,+2) 

end  for 
end  if 

return  valid.paths,  transJrusti 


-  (C,D) :  w(C,D)  0  c(C,D)  =  0.7  0  0.6  =  1  valid.paths  =  {(J,C),(C,D)} 

-  (D,K) :  w(D,K)  0  c(D,K)  =  0.8  0  0.6  =  1  valid.paths  =  {(J,C),(C,D),(D,K)} 

-  (C,B) :  w(C,B)  0  c(C,B)  =  0.6  0  0.5  =  1  valid.paths  =  {(J,C),(C,D),(D,K),(C,B)} 

-  (B,K) :  w(B,K)  0  c(B,K)  =  0.7  0  0.5  =  1  valid.paths  =  {(J,C),(C,D),(D,K),(C,B),(B,K)} 

-  (J,A) :  w(J,A)  0  c(J,A)  =  0.5  0  0.7  =  0  valid.paths  =  {(J,C),(C,D),(D,K),(C,B),(B,K)} 

-  (A,D) :  w(A,D)  0  c(A,D)  =  0.4  0  0.6  =  0  valid.paths  =  {(J,C),(C,D),(D,K),(C,B),(B,K)} 

-  (A,B) :  w(A,B)  0  c(A,B)  =  0.6  0  0.7  =  0  valid.paths  =  {(J,C),(C,D),(D,K),(C,B),(B,K)} 

-  Finally  valid  paths  =  {J,C,D,K},  {J,C,B,K} 

Since  we  have  found  two  valid  paths,  we  will  run  the  first  if  statement  of  the  algo¬ 
rithm  as  follows. 

-  transJrusti  =0  +  0.600.700.8=0.336 

-  transJrust2  =  0  +  0.6  0  0.6  0  0.7  =  0.252 

-  min  =  transJrusti  0  transJrust2  =  0.336  0  0.252 

transJrust2  =  0.252  is  the  minimum  transitive  trust  value.  Therefore  the  valid  path 
J,C,B,K  is  the  one  that  will  be  used  to  propagate  the  delegation  of  access  rights  from  J 
to  K. 
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5  Conclusion 


In  this  work,  we  formalized  a  trust-based  access  control  model  for  providing  fine¬ 
grained  access  in  smartphone  clouds.  The  model  extends  traditional  RBAC  with  the 
notion  of  trust  and  also  addresses  the  problem  of  trustworthy  delegations.  A  lot  of  work 
remains  to  be  done.  We  plan  to  analyze  this  model  and  detect  inconsistencies  and  errors 
in  the  policy  specification.  The  access  control  configuration  of  the  cloud  is  dynamic  in 
nature.  Towards  this  end,  we  plan  to  investigate  how  to  perform  access  control  analysis 
in  real-time  to  ensure  that  security  breaches  do  not  occur.  We  also  plan  to  deploy  this 
model  in  real-world  environments  and  study  its  impact  on  the  performance  and  usability 
of  cloud  applications. 
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